Subject: out-of-band signalling proposal

From: [email-masked]
Date: Wed, 11 Aug 93 22:30:31 EDT

Andy,
I am very interested to know more about the problem which your proposal
addresses, namely, the TCP receive window size going to zero.  I am
thinking that maybe this will only be temporary if it does happen.

- As I understand Shannon's proposal, he would always have buffers
  available for 100% of the sum of the outstanding windows at any
  instant in time (though not 100% of the sum of the optimal window
  sizes - Shannon correct me if I'm wrong).  Do you agree that with
  this approach, TCP would not encounter the condition you mention?

- In the more statistical model I've been promoting, I can see how
  the scenario could theoretically happen (although all efforts should
  have been exerted to prevent the congestion from even propagating to the
  TC, much less stopping it).  Let's assume that there are buffers used
  to take data from TCP, which are shared by different circuits.
  It seems to me that as long as there is one circuit still running,
  and the total of (data in both TCPs for the stopped circuits +
  committed windows for the stopped circuits) does not exceed total
  free buffer space in the receiver, TCP buffers should clear out and
  the unblocked circuits should run.  Do you agree / can anyone even
  understand what I just wrote?  I realize this sounds convoluted and
  like a lot of IFs, but it seems to me lots should have happened
  before we get into the state you describe.  Is there a scenario you
  can think of where we might get into this state very quickly and
  the circuit-level pacing not have a chance to respond?

- If we all agreed we didn't want two TCP connections per circuit
  as a general principle (or if the RFC had initially had only one),
  would you advocate adding a TCP connection for flow control
  messages, or would you seek to solve the problem some other way?

Thanks,
Peter

---

From: [email-masked] (Anand Subramaniam)
Date: Thu, 12 Aug 93 15:37:34 PDT

>   this approach, TCP would not encounter the condition you mention?

The TCP receive window is usually a function of the numbers of buffers 
available and also might be tied in with how fast the user is receiving and
swallowing the data. Some implementations usually cycle these buffers  and
hence are tied with the user's usage and the others allocate new buffers to
keep the window flowing. I don't think it is a good idea to assume that the
chances of hitting upon such a condition is rare because with so many data
link connections multiplexed over a single transport connection and  if some
of the buffers are stuck with a data link connection and the LAN side has
issued an RNR i,e it is on flow control, then we have these TCP buffers stuck
with the DL connection and can't do anything with it. This will definitely
affect other DL connections.

>   the circuit-level pacing not have a chance to respond?

	Yes. This could happen all the time as mentioned above.

>   messages, or would you seek to solve the problem some other way?
	We definitely  need 2 connections at the minimum. My model proposal mail
	just sent out addresses that. If we have only one connections we could
	have DISC ... interspersed with the data and it might be some time before
	the data link connections could get cleared.

	So on the TCP data stream(congested!!) we could have,

		DISC | CONNECT | DL DATA | CONNECT | DL DATA | DISC | DL DATA .....

	So all the control messages have to go on a different channel.

-- 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UUCP:  {ames,apple,sun,mtxinu}!excelan!andy         (Anand Subramaniam) |
| INTERNET:  [email-masked]                          Ph : (408)-473-8413 |
| " Now and then I go off in to my own little world; But they know me     |
|   there"                                                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+